Subject: Frame Relay Encapsulation for HPR

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 1 Apr 1996 14:25:00 -0500

This message proposes an amendment of the APPN High Performance Routing
Specification (HPR 5) to clarify the existing base support for Frame Relay
encapsulation, and an option set for extended encapsulation.  This is based
upon the discussion at AIW 10.

Section 6.2.1 is replaced as follows:

The frame relay formats for HPR are based on those described in the
"Multiprotocol Encapsulation Implementation Agreements FRF.3.1" by Rao
Cherikuri.

The frame relay header as currently defined for APPN FID2, that is with
level 2 protocol identifier X'4C80' indicating the presence of an IEEE 802.2
header, is used to transport XIDs, SABME, DISC, UA, and RR.  The SAPs used in
the 802.2 header are transmitted in non-canonical bit order, as on a
token-ring LAN.  An HPR link station does not send a TEST frame for route
discovery but responds if one is received.  Note that the unnumbered frames
always have the poll/final bit set.  For example XID is sent as X'BF', never
as X'AF'.

If link level error recovery is used on this link then I frames containing
NLPs are also transported using this format, but with level 3 protocol
identifier X'7085'.

If link level error recovery is not used on a link then base support is to
carry HPR NLPs in frames with the level 2 protocol identifier to X'5081'.
The HPR NLP immediately follows the level 3 protocol identifier (X'7085').
An HPR link station which supports the base function described in this
paragraph sends XIDs with a CV 61 which does not include a SF 80 and ignores
SF 80 in received CV 61s.

Optional support is for encapsulation of multiple HPR link connections within
a single frame-relay VC.  This support is desireable to simplify the
implementation of data link level gateways, and to minimize WAN connection
costs.  In this option HPR NLPs are carried in frames with level 2 protocol
identifier set to X'4C80', indicating the present of an IEEE 802.2 header,
Support for this option is signalled by the presence of a SF 80 in the CV 61.
This SF 80 must be present in this case, even if it has the default value
X'C8'.  The 802.2 header for transporting HPR NLPS without error recovery
contains SAPs as negotiated using the CV 61 SF 80 contents, and the UI
command code with the poll/final bit not set (X'03').

See the following frame relay formats for details.

 o A.2.1. "Frame Relay format for XID3 and FID2 Route Setup" on page A-53.

 o A.2.2. "Frame Relay format for HPR NLPs when not using link level error
   recovery" on page A-54.

 o A.2.3. "Frame Relay format for HPR NLPs when using link level error
   recovery" on page A-55.

 o A.1.11. "IEEE 802.2 LLC subfield (X'80')" on page A-35.

Section A.1.11 is amended as follows:

The section heading is changed to "IEEE 802.2 LLC subfield (X'80')".

The first paragraph is changed to:

This subfield is optionally included in CV 61 when XID3 is being exchanged
over a link which uses IEEE 802.2 LLC (e.g. Token-Ring, Ethernet, Frame
Relay).

The last Note is changed to:

Note: In the HPR base support for Frame-Relay this subfield is not sent.  The
presence of this subfield signals support for the SAP multiplexing option
over Frame-Relay.